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REMARKS 

Claims 1-4 and 15 are pending. Applicant has amended claims 1 and 15 herein. 
Applicant has cancelled the non-elected claims at the Examiner's request and reserves the 
right to pursue these claims in a future application. 

The Examiner rejected claim 15 under 35 U.S.C. §101 as being directed to 
nonstatutory subject matter, because the recited computer-readable medium could be a 
communication medium, such as a carrier wave. Applicant has amended claim 15 to recite 
a "computer-readable storage medium." Applicant's specification differentiates a 
communication medium from a storage mediumV Applicant respectfully submits that claim 
15 as amended meets the requirements of 35 U.S.C. § 101, and thus is directed to 
statutory subject matter. Accordingly, applicant respectfully requests that this rejection be 
withdrawn. 

The Examiner rejected claims 1-4 under 35 U.S.C. § 103(a) over Baugher ('The 
Secure Real-time Transport Protocol") in view of Minhazuddin (2004/0073641) and claim 
15 over Bontempi (2002/0150092) in view of Baugher. Applicant respectfully traverses 
these rejections. 

In response to applicant's previous arguments, the Examiner indicated that "the 
features upon which applicant relies (i.e., handling the routing of RTP packets when the 
destination address and port are not unique) are not recited in the rejected claim(s)." 
Office Action, October 19, 2007, p.3. Although applicant believes that this attribute was 
implicit in the previous claim language, applicant has nevertheless amended the claims to 
explicitly recite "the destination address and destination port of multiple receiving network 
clients are not unique from the perspective of a sending client." None of the references 
relied upon by the Examiner describes or handles the situation of a receiving client behind 



^ Applicant notes that whether data signals are patentable subject matter is currently being disputed in the 
courts. Applicant reserves the right to reintroduce claims directed to communication media in the future. 
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a firewall in which the destination address and port of multiple receiving clients are not 
unique. 

Baugher describes a protocol, called SRTP, for securing communications sent in 
accordance with the Real-time Transport Protocol (RTF). Like RTF itself, SRTF relies on 
a unique destination address and port for each receiving client. Baugher states, "[a] 
cryptographic context SHALL be uniquely identified by the triplet context identifier: context 
id = <SSRC, destination network address, destination transport port number>" and "[i]t is 
assumed that, when presented with this information, the key management returns a 
context with the [cryptographic context] information." Baugher, p. 9. However, in many 
situations, particularly where firewalls are involved, the number of available destination 
ports is severely limited such that it is not possible or desirable to assign each receiving 
client a unique destination port. Thus, the assumption stated in Baugher does not hold 
true for these situations because a destination address and port are insufficient to uniquely 
identify a particular context, even if combined with the SSRC value. Baugher does not 
address these situations and contains no teaching or suggestion of a method of handling 
the routing of RTF packets when the destination address and port are not unique. 

Similarly, Bontempi is directed to situations where each receiving client has a 
unique destination address and port that are used for routing: "UDF port 102 is reserved 
for one-to-one communication" and "[t]he leading packet 71 is routed to the U-UFF1 on the 
basis of the destination address." Bontempi, paragraphs [0067] and [0069]. The Examiner 
points to paragraph [0080] of Bontempi as routing packets exclusively according to the 
SSRC value in the RTF packet. However, the Examiner ignores the portion of Bontempi 
that describes how the destination address is first used to route the packets. As noted 
above with respect to Baugher, the SSRC is always a component of a triplet for uniquely 
identifying a stream. However, the SSRC alone is generally insufficient to uniquely identify 
a particular receiving client. As illustrated in Figure 7 of Bontempi, each device in the 
communication has a unique address and port. No two devices share an address and 
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port, and Bontempi contains no teaching or suggestion of a method of handling the routing 
of RTP pacl<ets when the destination address and port are not unique. 

In contrast, applicant's technology is directed to routing secure RTP traffic in an 
environment where destination ports are limited, such as a firewall. A firewall may contain 
a single IP address that is shared by many receiving clients. From a sender's point of view 
outside of the firewall, each of the receiving clients has the same destination address. If 
the firewall only allows RTP communications to be received on a particular port, then each 
of the receiving clients also appears to the sender to have the same destination port. 
Thus, when a packet is received at the firewall, there is no way provided by RTP for the 
firewall to determine which receiving client should receive the packet. Applicant's 
technology observes that the sender's information can be made unique in these situations, 
and uses the sender's information to determine which receiving client should receive the 
packet. 

In the embodiments of claims 1-4, applicant's technology distinguishes receiving 
clients based on the sender's source information in the RTP header. Claim 1 recites 
"determining whether a sending client's Security Association (SA) exists using the sender's 
source information included in the RTP message header" and "forwarding the packet to a 
receiving network client identified based on the sender's source information." In the 
embodiment of claim 15, applicant's technology distinguishes receiving clients based on a 
sender-provided Synchronization Source Identifier (SSRC). Whereas the SSRC value is 
typically chosen at random and need only be unique across the streams of a particular 
session, applicant's technology may, for example, manage SSRC values such that they 
are unique across multiple sessions. Claim 15 recites "wherein a receiving media relay 
server determines a receiving client associated with the data structure based on the 
unencrypted Synchronization Source Identifier without identifying a unique port for the 
receiving client." Thus, each of applicant's pending claims describes distinguishing 
receiving clients without relying on a unique destination address and port. 
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As discussed above, Baugher assumes a unique destination address and port for 
each receiving client and does not teach or suggest distinguishing receiving clients on any 
other basis. Similarly, Bontempi assumes a unique destination address and port for each 
receiving client and does not teach or suggest distinguishing receiving clients on any other 
basis. The SSRC value In Bontempi is used for its original purpose as described in the 
SRTP specification of Baugher for distinguishing streams within a single session. 
Minhazuddin, relied upon by the Examiner for teaching decrypting packets at a server, also 
does not teach or suggest distinguishing receiving clients where each receiving client does 
not have a unique destination address and port. Therefore, applicant's claims are 
patentable over Baugher, Bontempi, and Minhazuddin both alone and in combination. 
Accordingly, applicant respectfully requests that these rejections be withdrawn. 

Based upon these remarks and amendments. Applicants respectfully request 
reconsideration of this application and its early allowance. If the Examiner has any 
questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-3265. 

Applicants believe all required fees are being paid in connection with this response. 
However, if an additional fee is due, please charge our Deposit Account No. 50-0665, 
under Order No. 418268874US from which the undersigned is authorized to draw. 




Respectfully submitted, 




J. MasoV6oswell'' 



R^stration No.: 58,388 
PERKINS COIE LLP 
P.O. Box 1247 

Seattle, Washington 98111-1247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorneys for Applicant 
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